Collection of Internet/Collection of Internet.iso/infosrvr/doc/www_talk.arc/[e-mail] _Mon Nov 30 18:00:12 1992.msg

Internet Message Format | 1992-11-30 | 5KB

Return-Path: <[e-mail]>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
    id AA03341; Mon, 30 Nov 92 18:00:12 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
    id AA00620; Fri, 27 Nov 1992 19:48:03 +0100
Received: from kyle.eitech.com by eitech.com (4.1/SMI-4.1)
    id AA13149; Fri, 27 Nov 92 10:46:33 PST
Date: Fri, 27 Nov 92 10:46:33 PST
From: [e-mail] (Jay C. Weber)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: an idea for integrating WWW and MIME
Cc: [e-mail]

I've been reading this list second hand for a while (could someone put me
on the list, please?), and I have an idea that bears on a number of recent
messages regarding WWW and MIME.  In summary, the idea is to add a new WWW
document access type that refers to sibling parts of a MIME multipart, and
in so doing

  o integrates the MIME typing mechanism into WWW  (as Dan has championed)
    while making a MIME reader do the work (e.g., without requiring that an
    html parser parse content-types, nor that it know what how to handle
    those types);

  o provides a bundling mechanism (as Dave has requested) so the various
    media pieces are part of a single "compound document";

  o suggests a variation where the media pieces are physically part of the
    document layout (instead of being a button push away and a separate
    window (as I think Dave also requested);

  o allows for recursive embedding to create larger structures (like Dave's
    "books");

  o supports typing on either end of the link;

  o relates the WWW (remote) document names to MIME message/external-body
    types.

Right, so enough hype.  These compound documents are MIME multipart objects
like the following:

  Content-type: multipart/x-presentation; boundary=foo

  --foo
  Content-type: text/html

  You know, <a HREF=part:id1> the world </a> is a funny place.

  --foo
  Content-ID: id1
  Content-type: image/gif
  Content-description: an image of a globe
  Content-transfer-description: base64

  JKLAHFKHKJHL53645NBDL3W45Y5KYKN...

  --foo

A multipart/x-presentation is like a multipart/mixed (and will be treated
as such in simple MIME readers), except that the first part defines the
layout of the presentation.  The interesting case for this crowd is when
that part is an html document with references to the remaining parts.  In
the above example, I've implemented a reference through a new document
access type called "part", which looks for a sibling in the multipart with
content-id "id1".  De-referencing that HREF cranks up the MIME reader
(e.g., metamail) on that part.

Using this bundling mechanism, multiple media types can appear in a single
document (the granularity of the web should be defined on conceptual
grounds, not media boundaries!).  But the referenced parts can be of type
text/x-html, providing a bundling mechanism for portions of the web --
which at least partly addresses Daves request for book structures.  Note
that the bundled parts can even be of type multipart/x-presentation, so one
can recursively intermix media and web bundling.

One can also imaging an alternative to anchors ("frames"?) where the
referenced object gets physically embedded in the layout of the text
(someone must have done this in SGML by now).  Format-wise this would be
almost identical to my example above, and you could mix the two.

Note that the typing information is not in the anchor, it's in the
referenced part.  Of course, you could allow typing in the anchor and have
it default or override the typing in the part, but it seems to me that in
general you want the typing at the destination. (I've probably touched on a
controversial point.)  This is more important in my next point.

So I mentioned a relation between document naming in WWW and
message/external-body types in MIME.  Suppose that instead of including the
GIF image in the above example, I had the following:

  --foo
  Content-ID: id1
  Content-type: message/external-body; access-type=anon-ftp;
     site=eitech.com; directory=/pub; file=globe.gif
  Content-description: pointer to picture of globe

  Content-type: image/gif

  --foo--

When the reference to id1 is dereferenced, the MIME reader would fetch the
file from the remote site.  (The second content-type acts as a default for
the file type, which can be overridden by typing information in the
destination.) Thus the "part" document access type, through MIME
interactions, can do remote references; one could view the anchor

  <a HREF=anon-ftp://eitech.com/pub/globe.gif TYPE=image/gif>

as a shorthand for anchor referencing the external-body (do WWW addresses
have an anon-ftp access type?  MIME external-body and WWW access type sets
are overlapping; they could be sync'ed).

I've gone way past the length limit for optimal readership :-), but I hope
many of you (especially Dave and Dan) have gotten all the way through.
Comments?

Jay
---------------------------------------------------------------------
Jay C. Weber                    [e-mail]
Enterprise Integration Technologies        [e-mail]
459 Hamilton Avenue, Suite #100            [phone]
Palo Alto, CA 94301